ICTSC Tech Blog

ICTSC9のバックボーン解説 - SRX1500編

ICTSC9 ネットワーク関連

執筆担当: 新留

新留です。
HomeNOCと今回のコンテスト会場を接続する機材として、Juniper Networks(以下Juniper)様からお貸出しいただいたSRX1500を利用しました。
この機材では、Chassis Clusterでのクラスタ構成による冗長化やフルルートの受信と経路制御を行い、コンテスト参加者や運営、協賛とインターネットとの橋渡しを行っていました。

トポロジー図

ご満悦の表情でトラフィックを裁くSRX1500

Chassis Cluster

下流との接続と設定の簡略化、何よりロマンを求めて、今回はこの２台でChassis Clusterを構築し、Active-Activeとなるような構成にしました。
この構成のおかげで2つの機材の設定を1つのコンソール接続で管理でき、またルーティングテーブル・NAPTテーブルが同期されるため、とても便利でした。
Chassis Clusterを生かしてSRX1500と下流のQFX5100との接続をLAGで構築する予定もあったのですが、時間の都合で今回は達成することが叶いませんでした。

余談で、この設定はホットステージ開始前に行ったのですが、再起動必須なことを失念してリモートで設定投入 -> 再起動 -> 接続断 -> DCダッシュ ということをしてしまったのを今でも覚えています。

ルーティング

HomeNOCの説明でも軽く紹介した、大阪側から広告されたフルルートと東京側から広告されたデフォルトルートは、このSRX1500で受信していました。

HomeNOCから受けたIPv4 約69万経路 + IPv6 約5万経路をこの機材で収容し、ルーティングを行なっていました。
フルルートを受けている時の show bgp summary

受信経路の説明の図

また、SRX1500とその下流のQFX5100間ではOSPFで経路を広告していました。

内部経路の広報の図

SRX1500からはデフォルトルートを広告し、下流のQFX5100からはライフサーバー群、NAVT変換後のネットワーク、デバッグ用のチーム16（実際には存在しないチーム番号）を広告していました。OSPFでの経路数はトータルで30程度でした。

個人的に一番驚いたのが、ルーティングプロトコルでデフォルトルートを広告してくれるコマンドが存在しないことでした。
そのため、Juniperの公式HPにある情報などを頼りに以下の設定でデフォルトルートを広告しています。

set routing-options static route 0.0.0.0/0 discard
set routing-options static route 0.0.0.0/0 no-install
set routing-options static route 0.0.0.0/0 preference 200

set policy-options policy-statement bgp-redistribute term default from route-filter 0.0.0.0/0 exact
set policy-options policy-statement bgp-redistribute term default then accept

set protocols ospf export bgp-redistribute

この設定で、RIBに乗らない経路を作成し、その経路を広告するように設定しています。
Policy Statementの名前が bgp-redistribute なのは、BGPで流れてきたデフォルトルートを再広告する設定の名残です。
ちゃんと直さないとなあと思いながら本番が来てしまい、直せず仕舞いでした。

構築途中で「BGPで流れてきたデフォルトルートを再広告する設定」のミスにより、HomeNOCから来たフルルートをQFX5100にOSPFで再広告するという設定をしていました。
その結果、60万を超える経路を受信しようとしたQFX5100がハングアップし、その設定を行なった私は「うわあ・・・やっちまった・・・」とうなだれていました。

その直後にHomeNOCの山口様がこんなツイートを残していて、胸が痛くなりました。


十分勉強になりました、ありがとうございました。

ハングアップした原因としては、経路広告先であるQFX5100のIPv4の最大経路数が208,000経路であるにもかかわらず、69万もの経路を流してしまったため性能的に無理だったというものでした。
フルルートをOSPFで流した時の概要の図

また、事前の連絡ではデフォルトルートを大阪・東京双方から受信するという話で、そのため横着をしてBGPの経路をOSPFに広告する設定でデフォルトルートだけが広告されると想定し設定していました。
その設定途中でSRX1500にフルルートを流してみよう！ということになり、と同時にその時に再広告の設定を失念していた人的ミスのせいでQFX5100が一時応答不能になるというトラブルに発展しました。

やはり横着はよくない、eBGPで受けた経路をIGPに再広告するのではなく、きちんとDefault Gatewayを生成することが必要だとしっかり理解した瞬間でした。

このトラブル以外SRX1500でのトラブルはなく、とても安定して稼働してくれました。

コンテストを終えて

今回のコンテストでは、SRX1500で見た最大フロー数は7500程度、最大帯域は150Mbpsでした。
今回利用したネットワーク機材の中では通信量はそこまでないことがわかっていたのですが、フルルートが乗っているということもあり、私はCPU負荷やメモリ負荷といった部分を比較的注視して見ていました。
しかし、実際にコンテストが始まってからも多少の増減はありましたが特に詰まることなくパケットを処理している様子で、心配することはなかったなと思いながら見てました。
個人的な感想になりますが、Juniper機材を触ったことのなかった自分にとって新しい体験ができ、とても楽しく触らせていただきました。
機材提供をしていただいたJuniper Networks様、ありがとうございました。